Smartcards are portable devices that include logic and memory circuitry configured to interact with computers and other like devices. In a typical computer implementation, a computer includes or is otherwise connected to a smartcard interface device that operatively interacts with the smartcard to provide connectivity to the circuitry of the smartcard for applications and/or other processes operating within the computer. Once the applicable connections are made, the smartcard circuitry can operate as designed/programmed and begin processing requests received from the computer and/or otherwise support the operations of the computer.
Smartcards and other like mechanisms can be configured to support a wide variety of functions. By way of example, a smartcard may be configured to support user verification, service authorization and cryptographic processes. The circuitry on such smartcards typically includes processing logic and static memory that allows secret/preparatory data to be processed and stored within the smartcard in a secure manner.
Currently there are a variety of different manufactures designing and building smartcards, and hence there are different circuits with these smartcards. The smartcards are each designed to comply with certain standards, e.g., regarding the physical design, power requirements, communication interface, etc. This standardization allows different smartcards to utilize common smartcard interface devices, such as smartcard reader/writer devices that connect to computers.
Once a smartcard is operatively coupled to a computer (or other like device) then processes operating within the computer can send access requests to the smartcard through the established communication interface. For example, a software application running on a computer processing unit may request access to the smartcard by generating a smartcard access request to which the smartcard is responsive in some manner. For example, a smartcard may respond to the command(s) stated in a smartcard access request by processing some data and outputting data to the requesting software application, process and/or other like entity.
Since a smartcard can be accessed by a plurality of such entities, there is a need to control access to the smartcard. Typically, a smartcard is designed to handle only one request, or transaction, at a time. As such, arbitration logic or other like logic is usually provided to prevent multiple simultaneous transactions/access attempts. Such arbitration logic may be provided, for example, within the computer and/or smartcard interface device.
It has been found that at certain times smartcard operations can be relatively slow due in part to the amount of card input/output (I/O) being performed. For example, data read from a smartcard is typically only stored, or cached, locally to the consumer of the data. Here, for example, the consumer of the smartcard data may be a process running on a computer or other like computing device. In some situations smartcard data is not cached at all.
Therefore, certain pieces of smartcard data must be re-read every time the data is needed.
Most contemporary smartcard scenarios are adversely affected by such smartcard caching, or lack thereof, behavior. One example of a common scenario is user authentication, which for these reasons may be uncomfortably slow and therefore is viewed by many as less-desirable than more common, but potentially less secure, alternatives, such as, for example, password-based authentication.
Moreover, even when smartcard data is cached, no prior solution exists for keeping the data consistent and secure across multiple consumers, e.g., across multiple processes running on a computer system.
Consequently, there is a need for improved smartcard caching methods and apparatuses.